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ABSTRACT 

The  National  Institute  of  Standards  and  Teehnology’s 
(NIST)  Intelligent  Systems  Division  (ISD)  is  working  with 
the  material  handling  industry,  speeifieally  on  automated 
guided  vehieles,  to  develop  next  generation  vehieles.  ISD 
is  also  a  partieipant  in  the  Defense  Advaneed  Researeh 
Projeet  Ageney  (DARPA)  Learning  Applied  to  Ground 
Robots  (LAGR)  Projeet  embedding  learning  algorithms 
into  the  modules  that  make  up  the  Four  Dimensional/Real- 
Time  Control  System  (4D/RCS).  4D/RCS  is  the  standard 
referenee  model  arehiteeture  whieh  ISD  has  applied  to 
eontrol  many  intelligent  systems.  Teehnology  from  LAGR 
is  being  transferred  to  the  material  handling  industry 
through  the  NIST  Industrial  Autonomous  Vehieles  Projeet. 
This  paper  deseribes  the  4D/RCS  strueture  and  eontrol 
applied  to  LAGR  and  the  transfer  of  this  teehnology 
through  a  demonstration  to  the  automated  guided  vehieles 
industry. 

Keywords:  LAGR,  4D/RCS,  automated  guided  vehieles, 
hierarehieal  eontrol,  referenee  model  arehiteeture,  indus¬ 
trial  autonomous  vehieles 

1.  INTRODUCTION 

The  National  Institute  of  Standards  and  Teehnology’s 
(NIST)  Intelligent  Systems  Division  (ISD)  has  been 
studying  industrial  vehieles,  namely  automated  guided 
vehieles  (AGVs)  like  the  ones  shown  in  figure  1,  and  their 
applieation  to  manufaeturing  and  distribution  for  several 
years. 


Figure  1  -  Typical  AGVs  used  in  the  material  handling 
industry:  unit  load  (left),  forklift  (right) 

This  effort,  ealled  the  Industrial  Autonomous  Vehieles 
Projeet,  aims  to  provide  industries  with  standards, 
performanee  measurements,  and  infrastrueture  teehnology 
needs  for  the  material  handling  industry.  NIST  reeently 
sponsored  a  survey  of  AGV  manufaeturers  in  the  US, 


eondueted  by  Bishop  ^ ,  to  help  determine  their  “generation- 
after-next”  teehnology  needs.  Reeognizing  that  basie 
engineering  issues  to  enhanee  eurrent  AGV  systems  and 
reduee  eosts  are  being  addressed  by  AGV  vendors,  the 
study  looks  beyond  today’s  issues  to  identify  needed 
teehnology  breakthroughs  that  eould  open  new  markets  and 
improve  US  manufaeturing  produetivity.  Results  of  this 
study  are  deseribed  in  [1]. 

Within  the  survey  and  high  on  the  list,  AGV  vendors 
look  to  the  future  for:  redueed  vehiele  eosts,  navigation  in 
unstruetured  environments,  onboard  vehiele  proeessing,  3D 
imaging  sensors,  and  transfer  of  advaneed  teehnology 
developed  for  Department  of  Defense  to  this  industry. 
Current  AGVs  are  “guided”  by  wire,  laser  or  other  means, 
operate  in  struetured  environments  tailored  to  the  vehiele, 
have  virtually  no  3D  sensing  and  operate  from  a  host 
eomputer  with  limited  onboard-vehiele  eontrol. 

The  availability  of  AGVs  that  ean  operate  in 
unstruetured  environments  expands  the  market  to  inelude 
new  eustomers  in  printing  and  distribution,  for  instanee. 
Operations  in  these  industries  ean  be  quite  dynamie  sueh 
that  a  next-generation  AGV  must  adapt  quiekly  and  adroitly 
to  ehange.  AGVs  are  now  eapable  of  loading  tmek  trailers 
at  a  loading  doek,  but  laek  the  robust  3D  imaging  systems 
and  pereeption  algorithms  for  sueh  a  task.  The  same  is  true 
for  deteeting  and  avoiding  obstaeles  in  unstruetured  indoor 
environments  where  AGVs  are  typieally  used. 

For  over  30  years,  NIST  has  been  developing  a  stan¬ 
dard  eontrol  arehiteeture,  ealled  the  Real-time  Control  Sys¬ 
tem  (RCS),  that  allows  for  distributed  intelligent  eontrol 
and  plug-and-play  eontrol  algorithms  and  advaneed  3D 
sensors  and  vehieles  [2,  3].  4D/RCS  is  the  most  reeent 
version  of  RCS  developed  for  the  Army  Researeh  Lab  Ex¬ 
perimental  Unmanned  Ground  Vehiele  program.  ISD  has 
studied  and  used  4D/RCS  in  defense  mobility  [4],  transpor¬ 
tation  [5],  robot  eranes  [6],  manufaeturing  [7,  8]  and  sev¬ 
eral  other  applieations. 

In  the  past  year,  ISD  has  been  applying  4D/RCS  to  the 
DARPA  LAGR  program  [9]  whieh  aims  to  develop  algo¬ 
rithms  that  enable  a  robotie  vehiele  to  travel  through  eom- 
plex  outdoor  terrain.  The  goal  is  to  enable  the  eontrol  sys¬ 
tem  of  the  vehiele  to  learn  whieh  areas  are  traversable  and 
how  to  avoid  areas  that  are  impassable  or  that  limit  the 
mobility  of  the  vehiele.  To  aeeomplish  this  goal,  the  pro¬ 
gram  provided  small  robotie  vehieles  to  the  partieipants. 


^  Commercial  equipment  and  materials  are  identified  in  this 
paper  in  order  to  adequately  specify  certain  procedures.  Such 
identification  does  not  imply  recommendation  or  endorsement 
by  the  National  Institute  of  Standards  and  Technology,  nor 
does  it  imply  that  the  materials  or  equipment  identified  are 
necessarily  the  best  available  for  the  purpose. 
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The  vehicles  are  equipped  with  four  computer  proces¬ 
sors  (right  and  left  cameras,  control,  and  the  planner);  wire¬ 
less  data  and  emergency  stop  radios;  GPS  receiver;  inertial 
navigation  unit;  dual  stereo  cameras;  infrared  sensors; 
switch-sensed  bumper;  front  wheel  encoders;  and  other 
sensors  listed  later  in  the  paper.  Towards  fulfilling  the  US 
AGV  vendors  request  of  advancing  the  AGV  industry, 
NIST  also  equipped  the  vehicle  with  active  and  passive 
RFID  (radio  frequency  identification)  and  a  2D  laser  scan¬ 
ner  as  shown  in  Figure  10. 


GPS  Antenna 

Dual  stereo  cameras 

Computers,  IMU 
inside 
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Casters 
Drive  wheels 


Section  2  of  this  paper  describes  the  4D/RCS  Refer¬ 
ence  Model  Architecture  as  applied  to  the  (outdoor)  LAGR 
program  and  detailed  in  [10].  Section  3  follows  with  a 
description  of  the  4D/RCS  LAGR  controller  applied  to  an 
indoor,  unstructured  environment.  Section  4  is  a  conclu¬ 
sion  followed  by  acknowledgments  and  references  sections. 

2.  4D/RCS  Applied  to  LAGR 

The  4D/RCS  architecture  is  characterized  by  a  generic 
control  node  at  all  the  hierarchical  control  levels.  This 
node  has  three  principal  components:  Sensor  Processing, 
World  Modeling,  and  Behavior  Generation.  The  4D/RCS 
hierarchical  levels  are  scalable  to  facilitate  systems  of  any 
degree  of  complexity.  Each  node  within  the  hierarchy  func¬ 
tions  as  a  goal-driven,  model-based,  closed-loop  controller. 
Each  node  is  capable  of  accepting  and  decomposing  task 
commands  with  goals  into  actions  that  accomplish  task 
goals  despite  unexpected  conditions  and  dynamic  perturba¬ 
tions  in  the  world. 

At  the  heart  of  the  control  loop  through  each  node  is 
the  world  model,  which  provides  the  node  with  an  internal 
model  of  the  external  world  (Figure  3). 


Mission  Goal 


Figure  3.  The  fundamental  structure  of  a  4D/RCS  con¬ 
trol  loop. 


The  4D/RCS  architecture  for  EAGR  (Figure  4)  con¬ 
sists  of  two  levels.  This  is  because  the  size  of  the  EAGR 
test  areas  is  small  (typically  about  100  m  on  a  side  and  the 
test  missions  are  short  in  duration  -  typically  less  than  4 
minutes.) 

The  following  sub-sections  describe  the  type  of  algo¬ 
rithms  implemented  in  sensor  processing,  world  modeling. 


and  behavior  generation,  as  well  as  a  section  that  describes 
the  learning  algorithms  that  have  been  implemented. 


Figure  4.  Two-level  instantiation  of  the  4D/RCS  hierar¬ 
chy  for  LAGR. 


Sensory  Processing 

The  sensor  processing  column  in  the  4D/RCS  hierar¬ 
chy  for  EAGR  (Figure  4)  starts  with  the  sensors  on  board 
the  EAGR  vehicle.  Sensors  used  in  the  sensory  processing 
module  include  the  two  pairs  of  stereo  color  cameras,  the 
physical  bumper  and  infrared  bumper  sensors,  the  motor 
current  sensor  (for  terrain  resistance),  and  the  navigation 
sensors  (GPS,  wheel  encoder,  and  inertial  navigation  sys¬ 
tem).  Sensory  processing  modules  include  a  stereo  obstacle 
detection  module,  a  bumper  obstacle  detection  module,  an 
infrared  obstacle  detection  module,  an  image  classification 
module,  and  a  terrain  slipperiness  detection  module. 

Stereo  vision  is  primarily  used  for  detecting  obstacles. 
The  SRI  Stereo  Vision  Engine  [11]  is  used  to  process  the 
pairs  of  images  from  the  two  stereo  camera  pairs.  For  each 
newly  acquired  stereo  image  pair,  the  obstacle  detection 
algorithm  processes  each  vertical  scan  line  in  the  reference 
image  independently  and  classifies  each  pixel  as 
GROUND,  OBSTACLE,  SHORT  OBSTACEE,  COVER 
or  INVAEID.  Figure  5  illustrates  the  basic  obstacle  detec¬ 
tion  algorithm  [12]. 


Figure  5.  A  single  vertical  scan-line  detecting  the 
ground.  Pixel  0  is  altered  to  correspond  to  the  bottom  of 
the  vehicle  wheel.  Pixels  1,  2,  3,  8  and  9  are  ground  pixels 
due  to  shallow  slopes.  Pixel  4,  5,  6  and  7  are  obstacles  due 
to  steeper  slopes.  The  slopes  are  shown  by  the  direction 
vectors  on  the  bottom  of  the  figure. 

Pixels  that  are  not  in  the  3D  point  cloud  are  marked 
INVAEID.  Pixels  corresponding  to  obstacles  that  are 
shorter  than  5  cm  high  are  marked  as 
SHORT  OBSTACEE.  The  obstacle  height  threshold  value 
of  5  cm  was  chosen  such  that  the  EAGR  vehicle  can  ignore 
and  drive  over  small  pebbles  and  rocks.  Similarly,  COVER 


corresponds  to  obstacles  that  are  taller  than  1.5  m,  a  safe 
clearance  height  for  the  LAGR  vehicle. 

Within  each  reference  image,  the  corresponding  3D 
points  are  accumulated  onto  a  2D  cost  map  of  20  cm  by  20 
cm  cell  resolution.  Each  cell  has  a  cost  value  representing 
the  percentage  of  OBSTACLE  pixels  in  the  cell.  In  addi¬ 
tion  to  cost  value,  color  and  elevation  statistics  are  also 
kept  and  updated  in  each  cell.  This  map  is  sent  to  the  world 
model  at  the  current  level  and  to  the  sensory  processing 
module  at  the  level  above  in  the  4D/RCS  hierarchy.  Figure 
6  shows  a  view  of  obstacle  detection  from  the  operator 
control  unit  (OCU).  The  vehicle  is  shown  driving  on  a  dirt 
road  lined  with  trees  with  an  orange  fence  in  the  back¬ 
ground. 


Figure  6.  OCU  display  showing  original  images  (top), 
results  of  obstacle  detection  (middle),  and  cost  maps 
(bottom).  Red  represents  obstacles,  green  is  ground,  and 
blue  represents  obstacles  too  far  away  to  classify. 


World  Modeling 

The  world  model  is  the  system's  internal  representa¬ 
tion  of  the  external  world.  The  world  model  provides  a  site 
for  data  fusion,  acts  as  a  buffer  between  perception  and 
behavior,  and  supports  both  sensory  processing  and  behav¬ 
ior  generation.  It  acts  as  a  bridge  between  sensory  process¬ 
ing  and  behavior  generation  in  the  4D/RCS  hierarchy  by 
providing  a  central  repository  for  storing  sensory  data  in  a 
unified  representation.  It  decouples  the  real-time  sensory 
updates  from  the  rest  of  the  system.  The  world  model  proc¬ 
ess  has  two  primary  functions:  to  create  a  knowledge  data¬ 
base  and  keep  it  current  and  consistent,  and  to  generate 
predictions  of  expected  sensory  input. 

For  the  LAGR  project,  two  world  model  levels  have 
been  built  (WMl  and  WM2).  Each  world  model  process 
builds  a  two  dimensional  (200  x  200  cells)  map,  but  at  dif¬ 
ferent  resolutions.  These  are  used  to  temporally  fuse  infor¬ 
mation  from  sensory  processing.  Currently  the  lower  level 
(SPl)  is  fused  into  both  WMl  and  WM2  as  the  learning 
module  in  SP2  does  not  yet  send  its  models  to  WM.  Figure 
7  shows  the  WMl  and  WM2  maps  constructed  from  the 
stereo  obstacle  detection  module  in  SPl.  The  maps  contain 
traversal  costs  for  each  cell  in  the  map.  The  position  of  the 
vehicle  is  shown  as  an  overlay  on  the  map.  The  red,  yel¬ 
low,  blue,  light  blue,  and  green  are  cost  values  ranging 
from  high  to  low  cost,  and  black  represents  unknown  areas. 
Each  map  cell  represents  an  area  on  the  ground  of  a  fixed 
size  and  is  marked  with  the  time  it  was  last  updated.  The 
total  length  and  width  of  the  map  is  40  m  for  WMl  and  120 
m  for  WM2.  The  information  stored  in  each  cell  includes 
the  average  ground  and  obstacle  elevation  height,  the  vari¬ 
ance,  minimum  and  maximum  height,  and  a  confidence 
measure  reflecting  the  certainty  of  the  elevation  data.  In 


addition,  a  data  structure  describes  the  terrain  traversability 
cost  and  the  cost  confidence  as  updated  by  the  stereo  obsta¬ 
cle  detection  module,  image  classification  module,  bumper 
module,  infrared  sensor  module,  etc.  The  map  updating 
algorithm  is  based  on  confidence-based  mapping  as  de¬ 
scribed  in  [13].  The  costs  and  the  confidences  are  combined 
to  determine  the  relative  safety  of  traversing  the  grid  with 
cost  equations  detailed  in  [10]. 


Figure  7.  OCU  display  of  the  World  Model  cost  maps 
built  from  sensor  processing  data.  WMl  builds  a  0.2  m 
resolution  cost  map  (left)  and  WM2  builds  a  0.6  m  resolu¬ 
tion  cost  map  (right). 

The  final  cost  placed  in  each  map  cell  represents  the 
best  estimate  of  terrain  traversability  in  the  region  repre¬ 
sented  by  that  cell,  based  on  information  fused  over  time. 
Each  cost  has  a  confidence  associated  with  it  and  the  map 
grid  selects  the  label  with  the  highest  confidence.  The  final 
cost  maps  are  constructed  by  taking  the  fused  cost  from  all 
the  sensory  processing  modules. 

Efficient  functions  have  been  developed  to  scroll  the 
maps  as  the  vehicle  moves,  to  update  map  data,  and  to  fuse 
data  from  the  sensory  processing  modules.  A  map  is  up¬ 
dated  with  new  sensor  data  and  scrolled  to  keep  the  vehicle 
centered.  When  the  vehicle  moves  out  of  the  center  grid 
cell  of  the  map,  the  scrolling  function  is  enabled.  The  map 
is  vehicle-centered,  so  only  the  borders  need  to  be  initial¬ 
ized.  Initialization  information  may  be  obtained  from  re¬ 
membered  maps  saved  from  previous  test  runs. 

The  cost  and  elevation  confidence  of  each  grid  cell  is 
updated  every  sensor  cycle:  5  Hz  for  the  stereo  obstacle 
detection  module,  3  Hz  for  the  learning  module,  5  Hz  for 
the  classification  module,  and  10  Hz  to  20  Hz  for  the 
bumper  module.  The  confidence  values  are  used  as  a  cost 
factor  in  determining  the  traversability  of  a  cell. 


Behavior  Generation 


Top  level  input  to  Behavior  Generation  (BG)  (Figure 
8)  is  a  file  containing  the  final  goal  point  in  UTM  (Univer¬ 
sal  Transverse  Mercator)  coordinates.  At  the  bottom  level 
in  the  4D/RCS  hierarchy,  BG  produces  a  1.3  m/s  max. 
speed  for  each  of  the  two  drive  wheels  updated  every  20 
ms,  which  is  input  to  the  low-level  controller  included  with 
the  government-provided  vehicle.  The  low-level  system 
returns  status  to  BG,  including  motor  currents,  position 
estimate,  physical  bumper  switch  state,  raw  GPS  and  en¬ 
coder  feedback,  etc  These  are  used  directly  by  BG  rather 
than  passing  them  through  sensor  processing  and  world 
modeling  since  they  are  time-critical  and  relatively  simple 
to  process. 

Two  position  estimates  are  used  in  the  system.  Global 
position  is  strongly  affected  by  the  GPS  antenna  output  and 
is  more  accurate  over  long  ranges,  but  can  be  noisy.  Local 
position  uses  only  the  wheel  encoders  and  inertial  meas¬ 
urement  unit  (IMU).  It  is  less  noisy  than  GPS  but  drifts 
significantly  as  the  vehicle  moves,  and  even  more  if  the 
wheels  slip. 

The  system  consists  of  five  separate  executables. 


Each  sleeps  until  the  beginning  of  its  cycle,  reads  its  inputs, 
does  some  planning,  writes  its  outputs  and  starts  the  cycle 
again.  Processes  communicate  using  the  Neutral  Message 
Language  (NML)  in  a  non-blocking  mode,  which  wraps  the 
shared-memory  interface  [14].  Each  module  also  posts  a 
status  message  that  can  be  used  by  both  the  supervising 
process  and  by  developers  via  a  diagnostics  tool  to  monitor 
the  process. 


World  Modeling  Behavior  Generation 


position, motor  current,  wheei  speeds 
bumper,  etc. 


Figure  8.  Behavior  generation  high  level  data  flow  dia¬ 
gram. 

The  LAGR  Supervisor  is  the  highest  level  BG  module. 
It  is  responsible  for  starting  and  stopping  the  system.  It 
reads  the  final  goal  and  sends  it  to  the  waypoint  generator. 
The  waypoint  generator  chooses  a  series  of  waypoints  for 
the  lowest-cost  traversable  path  to  the  goal  using  global 
position  and  translates  the  points  into  local  coordinates.  It 
generates  a  list  of  waypoints  using  either  the  output  of  the 
A*  Planner  [15]  or  a  previously-recorded  known  route  to 
the  goal. 

The  planner  takes  a  201  X  201  terrain  grid  from  WM, 
classifies  the  grid,  and  translates  it  into  a  grid  of  costs.  In 
most  cases  the  cost  is  simply  looked  up  in  a  small  table 
from  the  corresponding  element  of  the  input  grid.  However, 
since  costs  also  depend  on  neighboring  costs,  they  are 
automatically  adjusted  to  allow  the  vehicle  to  continue 
motion. 

The  waypoint  follower  receives  a  series  of  waypoints 
spaced  approximately  0.6  m  apart  that  could  be  used  to 
drive  blindly  without  a  map.  However,  there  are  some  fea¬ 
tures  of  the  path  that  make  this  less  than  optimal.  When  the 
path  contains  a  turn,  it  is  either  at  a  0.8  rad  (45°)  or  1.6  rad 
(90°)  angle  with  respect  to  the  previous  heading.  The  way- 
point  follower  could  smooth  the  path,  but  it  would  at  least 
partially  enter  cells  that  were  not  covered  by  the  path  cho¬ 
sen  at  the  higher  level.  Other  features  are  detailed  in  [10] 
along  with  details  of  custom  behaviors  not  relevant  to  the 
indoor  behavior  generator.  However,  one  such  potential 
indoor  behavior  is  the  “Narrow  Corridor/Close  to  Obstacle” 
mode  that  turns  on  automatically  when  the  vehicle  is  in 
tight  spaces.  In  this  case  the  vehicle  slows  down,  builds  a 
detailed  world  model,  and  considers  a  larger  number  of 
alternative  paths  to  get  around  tight  comers  than  in  open 
areas. 

The  lowest  level  module,  the  LAGR  Comms  Interface, 
takes  a  desired  heading  and  direction  from  the  waypoint 
follower  and  controls  the  velocity  and  acceleration,  deter¬ 
mines  a  vehicle-specific  set  of  wheel  speeds,  and  handles 
all  communications  between  the  controller  and  vehicle 
hardware. 


Learning  Algorithms 

Learning  is  a  basic  part  of  the  LAGR  program.  Learn¬ 
ing  takes  place  in  all  three  4D/RCS  architecture  columns  - 
sensor  processing,  world  modeling,  and  behavior  genera¬ 
tion.  There  is  learning  by  example,  learning  from  experi¬ 
ence,  and  learning  of  maps  and  paths.  Most  learning  relies 
on  sensed  information  to  provide  both  the  learning  stimulus 
and  the  ground  tmth  for  evaluation.  In  the  LAGR  program, 
learning  from  sensor  data  has  mainly  focused  on  learning 
the  traversability  of  terrain.  This  includes  learning  by  see¬ 
ing  examples  of  the  terrain  and  learning  from  the  experi¬ 
ence  of  driving  over  (or  attempting  to  drive  over)  the  ter¬ 
rain. 

Model-based  learning  occurs  in  the  SP2  module  of  the 
4D/RCS  architecture,  taking  input  from  SPl  in  the  form  of 
labeled  pixels  with  associated  (x,  y,  z)  positions.  Classifica¬ 
tion  is  an  SPl  process  that  uses  the  models  to  label  the 
traversability  of  image  regions  based  only  on  color  camera 
data. 

An  assumption  is  made  that  terrain  regions  that  look 
similar  will  have  similar  traversability.  The  learning  works 
as  follows  [16].  The  system  constructs  a  map  of  the  terrain 
surrounding  the  vehicle,  with  map  cells  0.2  m  by  0.2  m. 
Each  pixel  passed  up  from  SPl  has  an  associated  red  (R), 
green  (G),  and  blue  (B)  color  value  in  addition  to  its  (x,  y, 
z)  position  and  label  (OBSTACLE  or  GROUND).  Points 
are  projected  into  the  map  using  the  (x,  y  z)  position.  Each 
map  cell  accumulates  descriptions  of  the  color,  texture, 
intensity,  and  contrast  of  the  points  that  project  into  it. 
When  a  cell  accumulates  enough  points,  it  is  ready  to  be 
considered  as  a  model.  To  build  a  model  we  require  that 
95%  of  the  points  projected  into  a  cell  have  the  same  label 
(OBSTACLE  or  GROUND). 

To  classify  a  scene,  only  the  color  image  is  needed.  A 
window  is  passed  over  the  image  and  color,  texture,  and 
intensity  histograms,  and  a  contrast  value  are  computed  as 
in  model  building.  A  comparison  is  made  with  the  set  of 
models,  and  the  window  is  classified  with  the  best  match¬ 
ing  model  if  a  sufficiently  good  match  value  is  found.  Re¬ 
gions  that  do  not  find  good  matches  are  left  unclassified. 

Figure  9a  shows  an  image  taken  during  learning.  The 
pixels  contributing  to  the  learning  are  shown  in  red  for 
obstacle  points  and  green  for  ground  points.  Figure  9b 
shows  a  scene  labeled  with  traversability  values  computed 
from  the  models  built  from  previous  data. 


(a)  (b) 

Figure  9.  Learning  by  example  images  overlaid  (a)  with 
red  (obstacles)  and  green  (ground)  and  (b)  with  traver¬ 
sability  information  as  magenta  (obstacles)  and  yellow 
(ground). 

3.  4D/RCS  Applied  to  Unstructured 
Facilities 

Changes  from  the  Outdoor  System 

A  number  of  changes  were  made  to  the  control  system 
in  order  to  transfer  the  military  outdoor  application  to  an 
indoor  industrial  setting.  Two  RFID  sensors  were  integrated 
into  the  vehicle  position  estimate.  An  active  tag  RFID  sys¬ 
tem  was  used  allowing  tuned  tags  to  be  placed  up  to  a  cou- 


pie  of  meters  away  from  the  onboard  vehiele  reeeiver  and 
giving  freedom  to  ehoose  their  loeation.  Tag  tuning  in- 
eluded  adding  a  simple  thin  metal  plate  mounted  to  the  tags 
baek  and  bent  to  tune  deteetion  regions  from  the  original  4 
m  down  to  about  2  m.  Tuning  required  initial  testing  for 
deteetion  range  prior  to  plaeement.  Also,  a  passive  RFID 
system  was  used  ineluding  tags  that  provide  a  more  aeeu- 
rate  vehiele  position  to  within  a  few  eentimeters.  RFID 
systems  updates  replaeed  the  outdoor  GPS  positioning 
system  updates  in  the  eontroller.  These  two  integrated 
systems  are  shown  in  Figure  10.  Available  passive  tags  ean 
be  proeured  and  integrated  into  the  eontroller  to  allow  the 
vehiele  to  get  even  more  aeeurate  positioning,  whieh  may 
be  required  near  maehines  or  tray  stations  typieally  used  by 
AGV’s. 


Laptop 

Batteries 

Passive  RFID  receiver 
and  tags 


Active  RFID  receiver 
and  tuned  tag 
2D  laser  scanner 


Figure  10.  LAGR/IAV  vehicle  at  demonstration  start 
position  (top)  and  after  heading  through  doorway 
(bottom). 


The  eontrol  system  also  needed  to  be  less  aggressive 
for  safety  of  people  and  equipment.  The  outdoor  system  is 
allowed  to  hit  a  tree  or  a  bush  and  never  stops  to  wait  for 
someone  or  something  to  get  out  of  the  way  during  a 
DARPA  test.  Instead  the  outdoor  system  will  either  turn 
around  eompletely  to  find  a  different  path  or  try  to  squeeze 
through  whatever  spaee  is  left.  AGVs  must  deteet  people 
or  objeets  in  the  path  of  the  vehiele  aeeording  to  the  Inter¬ 
national  Assoeiation  of  Seienee  and  Teehnology  for  Devel¬ 
opment  (lASTED)  B56.5  Industrial  Tmek  Safety  Standard 
[17],  whieh  provided  guidelines  for  our  indoor  demonstra¬ 
tion.  Furthermore  the  indoor  setting  ineluded  tighter  eor- 
ners  than  are  typieally  eneountered  outdoors.  Unfortu¬ 
nately,  the  only  way  to  adequately  meet  the  eonflieting 
goals  of  negotiating  tighter  eomers  while  maintaining 
wider  standoff  margins  was  to  slow  the  vehiele  by  about 
50%  to  approximately  0.6  m/s. 

The  obstaele  deteetion  height  was  also  ehanged  for  the 
indoor  demonstration.  Outdoors,  it  proved  better  to  avoid 
even  fairly  short  obstaeles  sueh  as  logs  and  roots  that  eould 
sometimes  get  eaught  under  the  wheel  and  either  stop  the 
vehiele  or  eause  signifieant  wheel  slip.  Indoors,  the  obsta¬ 
ele  height  threshold  was  raised  from  5  em  to  30  em  sinee 
small  obstaeles  were  not  eommon.  Also,  the  uniformity  of 
the  floor  made  the  range  estimates  from  stereo  vision  less 
aeeurate  than  the  ground  outdoors,  eausing  false  obstaeles 
to  be  deteeted  due  to  poor  stereo  eorrelation.  A  2D  laser 
seanner  was  also  added  and  will  soon  be  integrated  into  the 


eontroller  to  allow  better  path  planning  by  removing  the 
false  obstaeles  deteeted  with  stereo  vision. 

Demonstration  Results 

On  April  10,  2006,  several  vendors  and  users  of  auto¬ 
mated  guided  vehieles  met  at  NIST  for  an  lASTED  B56.5 
Safety  Standard  meeting.  As  part  of  the  meeting,  attendees 
watehed  a  demonstration  of  the  EAGR  robot  navigating 
through  an  unstruetured  environment  ineluding  a  garage 
and  a  working  maehine  shop.  The  robot  was  started  next  to 
its  eharging  station  in  the  autonomous  vehieles  laboratory 
(garage).  It  deteeted  a  passive  RFID  tag  plaeed  on  the  floor 
and  updated  its  knowledge  of  its  eurrent  position  at  the  start 
point  of  the  route  (see  Figure  10).  A  laptop  on  the  robot 
displayed  an  overlay  of  the  live  video  from  eaeh  of  the  two 
stereo  eolor  eamera  pairs,  with  obstaele  deteetion,  eolor 
elassifieation,  and  2D  range  information,  as  well  as  a  high- 
resolution/short  range  map  and  a  lower  resolution/longer 
range  map  of  the  faeility  (see  Figure  11). 


Figure  11.  LAGR  AGV  Graphical  Displays  -  right  and 
left  stereo  images  (upper  left);  images  overlaid  with  stereo 
obstacle  (red)  and  floor  (green)  detection  and  2D  scanner 
obstacle  detection  (purple)  (middle  left);  right  and  left  cost 
maps  (lower  left);  low  level  map  (upper  right);  and  high 
level  map  (lower  right). 


The  robot  has  a  programmed  stored  path  shown  in  pink 
on  the  high  level  map.  The  measurements  taken  when 
building  the  map  were  not  very  aeeurate,  and  were  rounded 
to  within  a  meter.  Further,  straight  lines  were  used  as 
estimates  of  the  true  path.  Therefore,  there  is  a  fair  amount 
of  error  in  its  measurement  of  heading.  If  it  blindly 
followed  the  pink  path  it  would  run  into  the  yellow  eabinet. 
The  disparity  between  the  two  eamera  images  in  eaeh 
stereo  pair  provides  an  estimate  of  range  to  eaeh  seetion  of 
the  eabinet.  From  the  range  estimate,  the  slope  and  height 
of  the  eabinet  are  determined.  Sinee  tall  and/or  vertieal 
surfaees  should  be  avoided,  both  maps  are  updated  with  an 
obstaele  where  the  eabinet  is  loeated. 

Obstaeles  are  shown  as  red  overlays  in  the  image  and 
as  brown/red  marks  in  the  map.  The  robot  then  ehooses  a 
path  slightly  to  the  left  of  the  eabinet.  Given  its  ability  to 
sense  the  relative  position  of  obstaeles,  the  robot  does  not 
need  a  partieularly  aeeurate  positioning  system.  It  drives 
forward  updating  its  position  using  only  the  wheel  eneoders 
and  inertial  measurement  unit  (IMU)  for  about  8  m  until  it 
senses  the  aetive  RFID  tag  mounted  on  a  portable  stand  just 
before  the  point  where  it  will  need  to  turn  0.8  rad  (90  deg) 
to  exit  the  room.  It  ean  sense  this  tag  from  about  2  m  away. 
If  the  tag  eould  have  been  deteeted  farther  away  it  eould 
not  update  the  position  as  aeeurately.  If  the  deteetion  range 
were  more  limited  there  would  be  an  inereased  risk  of 
passing  the  tag  without  deteeting  it. 

When  this  tag  is  deteeted,  both  the  eurrent  position 
estimate  and  heading  are  eorreeted.  The  heading  is 


corrected  by  comparing  the  difference  between  the 
measurements  made  using  the  IMU  and  encoder  data  at  the 
first  passive  RFID  tag  near  the  charger  with  the  known 
locations  of  each  tag  from  a  table  stored  previously.  For 
example  if  the  IMU/encoder  output  had  indicated  that  the 
vehicle  had  gone  northwest,  but  the  second  tag  is  known  to 
be  north  of  the  first  the  current  IMU/encoder,  heading 
should  be  corrected  0.4  rad  (45°)  clockwise.  The 
programmed  path  indicates  a  left  turn  just  after  the  position 
associated  with  the  active  RFID  tag.  The  robot  turns  left, 
primarily  relying  on  stereo  to  find  a  doorway  to  pass 
through  and  onto  the  shop  floor  and  on  for  another  ten 
meters  until  passing  over  another  passive  RFID  tag. 

The  programmed  path  includes  annotations  to  pause  at 
certain  positions,  including  the  position  of  this  tag.  If  this 
vehicle  had  the  ability  to  carry  parts,  for  example,  instead 
of  simply  pausing,  the  tag  could  trigger  a  docking 
maneuver  to  load  or  unload  parts  during  this  pause.  After  a 
timer  counts  down,  the  robot  resumes  movement  and 
continues  on  its  approximately  planned  path.  The 
programmed  path  down  the  lane  is  simply  a  straight  line, 
but  the  robot  can  not  drive  a  straight  trajectory  since  the 
lane  is  partially  blocked  on  one  side  by  a  set  of  lockers  and 
on  the  other  at  different  locations  by  chairs,  trash  cans, 
machines,  etc. 

The  robot  is  programmed  to  stop  only  if  necessary, 
such  as  if  a  person  is  standing  in  the  center  of  the  lane.  It 
will  adjust  its  trajectory  if  the  lane  is  only  partially  blocked 
and  it  can  still  find  a  path  wide  enough  for  itself  and  an 
additional  safety  margin.  In  this  case,  it  continues  past  the 
obstacles.  The  robot  continues  on  its  preplanned  path,  turn¬ 
ing  at  each  of  three  additional  active  tags  before  coming  to 
a  halt  at  a  final  passive  tag  about  70  m  from  the  start  posi¬ 
tion. 

4.  Conclusions 

The  NIST  4D/RCS  reference  model  architecture  was 
implemented  on  the  DARPA  LAGR  vehicle,  which  was 
used  to  demonstrate  learning  in  this  architecture.  Sensor 
processing,  world  modeling,  and  behavior  generation  proc¬ 
esses  have  been  described  in  this  paper. 

Based  on  results  of  a  next  generation  study  for  the 
AGV  industry,  a  demonstration  was  developed  at  NIST 
using  the  LAGR  vehicle  and  controller  with  additional 
sensors  and  enhanced  processes.  The  demonstration  was 
shown  to  the  AGV  industry  resulting  in  collaborative  ac¬ 
tivities  with  the  industry  expected  in  the  near  future. 

Future  research  will  include  integration  of  the  2D 
safety  sensor  to  eliminate  false  positives  on  obstacles  near 
ground  level  caused  by  low  stereo  disparity.  Demonstra¬ 
tion  of  controlling  more  than  one  intelligent  vehicle  at  a 
time  in  unstructured  environments  with  other  moving  ob¬ 
stacles  will  be  studied. 
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